Network storage system

ABSTRACT

A network storage system for providing many clients with file services is structured to enable layered management of clients. A client management device is disposed between each client and a network file device provided with a disk unit. The network file device allocates a disk area to the client management device, and sets and manages access privileges of the client management device. The client management device allocates a disk area to each clients and sets and manages the access privileges of each client.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method for managing clients of anetwork storage system efficiently.

2. Description of Related Art

In recent years, storages have been expanded in capacity and reduced inprice. Especially, with the progress of the techniques related tomagnetic disks for realizing high recording density, it is about to berealized that one housing of storage comes to have a capacity of severaltens of terabytes, which has been impossible so far.

On the other hand, networks have also been enhanced. In recent years,there have appeared even low priced networks that realize transfer ratesof one gigabits/sec to 10 gigabits/sec. Conventional networks have beenlimited in transfer rate just within 10 megabits/sec to 100megabits/sec, so that it has been difficult to build up an efficientsystem for transferring mass of data; the conventional system transferperformance is often degraded significantly when many users attempt toaccess a network concurrently. However, it cannot be impossible to buildup a system that meets such requirements with use of a network of whichtransfer rate is one gigabits/sec to 10 gigabits/sec.

Under such circumstances, much attention is paid now to a networkstorage system, which is connected to a network and the users (clients)of the system are permitted to access the data stored in a commonstorage through the network. For example, JP-A No. 196961/2002 disclosesa configuration of such a network storage system. In that system, anetwork connecting part, a server processing part, and a disk unit aredisposed in the same housing. Each client accesses the common storagethrough the network using a communication method provided from theserver, thereby the clients can input/output data stored in the serverconnected to the network as if the data is stored in itself.

One of the problems that must be solved with respect to such networkstorage systems that are getting to be expanded in scale is how tomanage the storages. As a storage is expanded in scale, the method formanaging the performance and its clients comes to be complicated. Forexample, JP-A No. 132455/2002 discloses such a method for managing alarge-scale storage. According to the method, a large-scale memory unitfor caching clients' data is connected to a subject network. This methodis often employed to solve problems that might occur when in realizingof large scale high performance storages. On the other hand, JP-A No.67187/2001 discloses a method for managing clients. The method enables afew managers to manage clients of storages disposed in a single housing.

A small scale storage can be managed by a few managers, since the numberof clients is small. In the case of a large scale magnetic disk,however, the total capacity of one storage housing often becomes severaltens of terabytes. In such a case, it is expected that the number ofclients becomes several thousands to several tens of thousands.Management of clients mentioned here means allocating a storage area toeach client and setting an access privilege for the client with respectto the allocated area. For example, each client comes to have a network(IP) address, a disk area name (/user/a), an access privilege (toread/write data from/to the allocated disk area), etc. set for theclient. If such a client moves, the setting of the client must beupdated.

SUMMARY OF THE INVENTION

In order to solve the above conventional problems, the present inventionprovides a network storage system, which is connected to a network towhich a plurality of clients are connected. The network storage systemcomprises a network file device for managing a plurality of disk devicesand a client management device for relaying access requests from theclients to the disk devices, translating addresses of the clients to itsown addresses so as to enable accesses to the disk devices.Consequently, a plurality of clients come to look like one client groupfrom each disk device, so that the system can omit a process for settingdata for each client individually.

According to another aspect of the present invention, the networkstorage system is connected to a network to which a plurality of clientsare connected. And, the system includes a network file device formanaging a plurality of disk devices and a client management device forrelaying access requests issued from clients to the disk devices. Thenetwork file device allocates a predetermined area of each disk deviceto the client management device, which then divides the allocated areaand allocates the divided areas to the plurality of clients.Consequently, each disk device can regard a group consisting of aplurality of clients as the minimum unit to allocate one area to thegroup, thereby the system can omit a process for setting data for eachclient individually.

Furthermore, the network file device has a primary cache for storingcopy information, which is at least part of the disk device information.The client management device has a secondary cache for storing part ofthe copy information stored in the primary cache and corresponding tothe predetermined area allocated itself. Consequently, the clientmanagement device can speed up accesses apparently. The network filedevice and the network storage system may be united into one orseparated from each other and connected to each other through a network.

Furthermore, in order to solve the above conventional problems, thenetwork storage system of the present invention is configured by a firstdevice provided with a disk device and a second device for connecting aplurality of clients. The first and second devices are used to managethe plurality of clients in layers, thereby management of the clientscan be done efficiently. More concretely, the first device allocates anarea to the second device and sets an access privilege for the seconddevice while the second device sets data for each client individually.The second device is usually provided for each network area and requiredto manage only the corresponding network area. Furthermore, the seconddevice transfers each access request issued from each client to thefirst device. At that time, the second device translates IP addresses ofa plurality of clients into one IP address and adds a disk area nameallocated particularly to itself to the name of the disk area to access.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an overall block diagram of a network storage system in thefirst embodiment of the present invention;

FIG. 2 is a block diagram of a network of the present invention;

FIG. 3 is another block diagram of the network of the present invention;

FIG. 4 is a structure of client management information in a network filedevice;

FIG. 5 is a structure of client management information in the firstembodiment of the present invention;

FIG. 6 is a structure of disk management information in the firstembodiment of the present invention;

FIG. 7 is a flowchart of the processings of a virtual network filefacility;

FIG. 8 is a flowchart of a write processing;

FIG. 9 is a flowchart for writing data to a cache;

FIG. 10 is a flowchart for reading data from the cache;

FIG. 11 is a structure of a network packet;

FIG. 12 is a flowchart of the processings of an IP address translationfacility for sending data;

FIG. 13 is a flowchart of the processings of the IP address translationfacility for receiving data;

FIG. 14 is a procedure for translating an IP address and changing a filename;

FIG. 15 is a structure of an IP address translation table;

FIG. 16 is a flowchart of the processings of a negotiation facilityprovided in the client management device;

FIG. 17 is a flowchart of the processings of the negotiation facilityprovided in the network file device;

FIG. 18 is a procedure for migrating a client;

FIG. 19 is a structure of a file management table;

FIG. 20 is a flowchart of the processings of a client migration facility(source);

FIG. 21 is a flowchart of the processings of a client migration facility(destination);

FIG. 22 is an overall block diagram of a network storage system in thesecond embodiment of the present invention; and

FIG. 23 is a block diagram of a network in the second embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment

Hereunder, a description will be made in detail for a clients managingmethod in the first embodiment of the present invention with referenceto the accompanying drawings.

FIG. 1 shows a schematic block diagram of a network storage system inthe first embodiment of the present invention. Reference numeral 101denotes a client management device, which is roughly divided into aclient control facility (102), a client management table (103), an IPaddress translation table (120), a device capacity table (104), and acache (110). The number of the client management devices (101) can beincreased to two or more for each network. The client management device(101) manages disk areas used by the clients of each network and whetherto enable each client to be connected to the allocated area. The clientcontrol facility (102) is configured by a virtual network facility(105), an IP address translation facility (106), an administrationfacility (107), a negotiation facility (108), and a client migrationfacility (109). The client control facility (102) is connected to anetwork file device (111). The network file device (111) retainsclients' data. The network file device (111) is configured by anegotiation facility (112), a network file facility (113), a clientmanagement table (114), a cache (115), and a disk (116). The clientmanagement device (101) allocates a disk area supplied from the networkfile device (111) to each client, manages whether to enable each clientto be connected to the allocated disk area, and the clients themselves.

FIG. 2 shows the position of the client management device in the networkstorage system in this first embodiment. The clients (201 to 208) areconnected to their networks (209, 210) respectively. The clientmanagement devices (211, 212) are also connected to their networks (209,210) and their common network file device (214) through a backbonenetwork (213). All the clients (201 to 208) can access the network filedevice (214) through their client management devices (211, 212). Thebackbone network 213 is dedicated to the network file device (214). Theclient management device (211) controls/manages the clients (201 to 204)connected to the network (209). The client management device (212)controls/manages the clients (205 to 208) connected to the network(210). Because the client management device is employed in this firstembodiment, the managers of the network file device is not requirednecessarily to manage all the clients (201 to 208); each of the managersis just required to manage his/her client management device (211, 212).

On the other hand, FIG. 3 shows a general method for using a clientmanagement device. The clients (301 to 308) are connected to theirnetworks (309, 310) while the client management devices (311, 312) areconnected to their networks (309, 310) just like the clients (301 to308). In this case, each network is not dedicated to the network filedevice (314); it may also be used for other purposes. When compared withthe configuration shown in FIG. 2, the networks (309, 310, 313) are usedmore widely for various purposes. Therefore, the network security of thenetworks shown in FIG. 2 may be higher. The client management device(311) controls/manages the clients (301 to 304) connected to the network(319). The client management device (312) controls/manages the clients(305 to 308) connected to the network (310). Because the clientmanagement device shown in FIG. 2 is employed in this first embodiment,the managers of the network file device are not necessarily to manageall the clients (301 to 308); each of the managers is just required tomanage his/her client management device (311, 312). The configurationand effect shown in FIG. 3 are the same as those shown in FIG. 2. Theclient management device in this first embodiment can apply to both ofthe client management devices shown in FIGS. 2 and 3.

FIG. 4 shows a general structure of the client management deviceprovided in the network file device. This management tables (103, 114)shown in FIG. 1. A column 401 describes disk directories (404 to 406) ina disk (410). A column 402 describes IP addresses of clients whodisclose the directories described in the column 401. A column 403describes attributes of the directories. An attribute “read/write”enables both reading and writing. An attribute “read” enables onlyreading (and disables writing). The client management table mustdescribe all the connected clients. Now that the disk capacity isgetting to increase, tens of thousands of clients must often be managedand accordingly, the work load of the client management table managerbecomes heavy.

FIG. 5 shows a structure of the client management table in this firstembodiment. In this first embodiment, the client management table isstructured in layers. Reference numeral 509 denotes a client managementtable (114) provided in the network file device and reference numeral501/502 denotes a client management table (103) provided in the clientmanagement device (101). A column 510 describes directories in thenetwork file device, which are disk areas supplied to the clientmanagement devices (501, 502). A column 511 describes IP addresses ofthe client management devices (501, 502). A column 512 describesattributes opened to the client management devices (501, 502). Columns503 and 506 describe directories in the network file device, which aredisk areas supplied to the clients. Columns 504 and 507 describe IPaddresses of clients. Columns 505 and 508 describe attributes opened tothe clients. In this first embodiment, the manager of the network filedevice (509) is just required to manage his/her client management device(501, 502), so that his/her management load is reduced significantly.The client management device (501, 502) enables the client manager tocorrespond to the form of each network. The manager of the clientmanagement device (101) shown in FIG. 1 controls the client managementdevice (102) through the administration facility (107). Usually, themanager accesses the administration facility (107) through a network. Atthis time, the administration facility (107) requests the user to inputboth user identifier and password to enable the user to control theclient management device (102) after the user is authenticated. Theadministration facility can also give instructions to the clientmigration facility (109) to be described later and receive responses ofprocessings therefrom.

FIG. 6 shows an image of a disk in this first embodiment. Client data isstored in a disk 116 shown in FIG. 1. In this first embodiment, theclient management device divides a disk (601) into a plurality ofvirtual disks (602, 603). The reference numerals 602, 603 denotedirectories in a disk (601) opened to the client management device. Theclient management device has a function for making the clients thinkthat the directory 602 or 603 is actually an existing disk. The clients'areas managed by the client management device that has a directory 602are denoted with 604 to 606. The clients' areas managed by the clientmanagement device that has a directory 603 are denoted with 607 to 609.This function is mainly used to improve the disk security. In theconventional client management method, many user data items have beenstored one-dimensionally in a large scale disk. And, this has oftencaused errors in directory attribute setting, resulting in leakage ofinformation to many other clients. In this first embodiment, referencesto virtual disks can be limited by making a single disk look like aplurality of virtual disks from each client. This makes it possible tominimize such information leakage.

Next, this first embodiment will be described more in detail withreference to the accompanying drawings.

FIG. 7 shows a flowchart of the processings of the virtual network filefacility (105). In step 701, the facility (105) accepts a request from aclient. In step 702, the facility (105) checks whether the request is aread request or write request. If the request is a read one, controlgoes to step 705. If the request is a write one, control goes to step703. In step 703, the facility (105) calculates a disk capacityallocated to the network file device (111). This calculation is madewith a general method for converting a directory capacity into a diskcapacity. In step 704, the facility (105) checks whether or not thewriting is done over a predetermined disk capacity. This check is madeaccording to the predetermined capacity described in the device capacitytable shown in FIG. 1, the actually stored data capacity, and thecapacity of the data to be written. If the predetermined capacity is tobe exceeded, control goes to step 707 in which the facility (105)notifies the client of the capacity shortage. If writing is possible,control goes to step 706 in which the facility (105) writes the data. Instep 705, the facility (105) reads data. The write and read processingsin steps 706 and 705 will be described in detail later. In this firstembodiment, the limitation set in step 704 prevents a specific clientfrom occupying the disk capacity. In each conventional network filedevice, it has been difficult to limit the capacity of each diskdirectory. However, this function makes it possible to distribute a diskcapacity to each client equally.

FIG. 8 shows a flowchart of the write processing. In step 801, thefacility (105) makes disk address translation. This step is one of thefeatures of this first embodiment. As shown in FIG. 6, the clientmanagement device has a function for creating virtual disks. If a clientis to write data in a directory /user/A/file1, the client managementdevice adds a directory name /HUB01 allocated to itself to the requestfrom the client and translates the disk address to /HUB01/user/A/file1.Although this /HUB01/user/A/file1 is the original directory, thefacility (105) makes such disk address (directory) translation in step801 so that the client does not know the translation. In step 802, thefacility (105) writes the data in the cache (110), then ends thewriting. The data written in the cache (110) is written to the networkfile device (111) periodically in the cache write processing as shown inFIG. 9.

FIG. 9 shows a flowchart for writing data stored in the cache (110) ofthe client management device to the network file device (111). Thisprocessing is executed periodically, for example, every 30 seconds. Instep 901, the facility (105) checks how much a free space is left in thecache (110). If the free space is, for example, over 20% of the wholecache (110), the facility (105) ends the processing without writing anydata in the cache (110). If the free space is not sufficient, controlgoes to step 902, in which the facility (105) generates a networkpacket. The client management device and the network file device areconnected to each other through a network. Data to be transferredbetween those devices must be grouped as network packets. In step 905,the facility (105) encodes the data. This is to further improve thecommunication security. In step 903, the facility (105) sends thenetwork packet generated in step 902 and encoded in step 905 to theobject. In step 904, the facility (105) analyzes whether or not the datais sent to the object normally.

FIG. 10 shows a flowchart of a read processing. In step 1001, thefacility (105) makes disk address translation. This is the sameprocessing as that in step 801 shown in FIG. 8, that is, translating aread file address to an address stored actually in the network filedevice. In step 1002, the facility (105) checks whether or notpredetermined data exists in the cache. If the check result is YES(exist), control goes to step 1010. If the check result is NO (notexist), control goes to step 1003, in which the facility (105) generatesa network packet. This is the same processing as that in step 902 shownin FIG. 9. In step 1004, the facility (105) makes IP addresstranslation, which translates the IP addresses of many clients to asingle IP address to be transferred to the network file device (111).With this processing, the network file device (111) comes to be able toprocess requests from many clients just like requests from one client.The details of this processing will be described later. In step 1005,the facility (105) transfers the generated network packet to the networkfile device (111). In step 1006, the facility (105) receives data fromthe network file device (111) and analyzes the communication state. Ifan error occurs in the communication, control goes back to step 1003,then the facility repeats the processings in and after the step 1003. Instep 1008, the facility (105) decodes the data. In step 1009, thefacility (105) stores the read data.

Consequently, the facility (105), upon the next access to the data,reads the data from the cache, thereby speeding up the read processing.In step 1010, the facility (105) transfers the read data to the subjectclient.

Next, the IP address translation facility (106) will be described.

FIG. 11 shows a general structure of a network packet. In FIG. 11,reference numerals are defined as follows; 1101 to 1104 denote IP(Internet Protocol) packets, 1105 to 1108 denote data items set in theIP packet, 1101 denotes a destination IP address and 1102 denotes asource IP address. An IP address is a client/server address used toidentify a network to which the client/server is connected. An IPaddress must be unique at least in one network. IP addresses of bothsource and destination are specified to begin the communication betweena client and a server, between clients, and between servers. In the area1103 are set options for the subject IP communication. In the area 1104is stored IP data. Client data is never stored directly in the IP dataarea. If such an IP packet is lost during communication, no action istaken for it basically. In this connection, processings for checking ifan IP packet is lost and determining whether to send the IP packet againif it is lost must be described in the program for sending/receiving IPpackets independently. However, this may cause various types of transfermethods to be used in networks and communication compatibility amongthose networks to be lost, thereby the communication programs arecomplicated. And, to avoid such problems, a method has been employed.The method adds a layer to the protocol for realizing more enhancedprocessings than those of the IP and wrapping IP packets with the layer,thereby improving the compatibility and controllability of the networks.The data set in the areas 1105 to 1108 are related to such a layer.Usually, the data is referred to as TCP (Transmission Control Protocol)data. BY wrapping each IP packet with such TCP data provided withfunctions for re-sending, etc., the controllability and reliability ofthe communication can be improved more. In the area 1105 is set adestination port number and in the area 1106 is set a source portnumber. The port number is classified into two types; a number assignedto such a service as a file service and a mail service or such afunction and a number decided by an operating system independently. Forexample, when a client requests a server for a file service, a uniquenumber corresponding to the file service is assigned to the destinationport and a unique number that is not used by the subject operatingsystem is assigned to the source port. This port number is used toidentify each client with respect to each service and send/receive TCPdata to/from the client correctly. Options corresponding to the TCP areset in the area 1107. Application data is stored in the area 1108. For afile service, file I/O data is stored in the application data area(1108).

FIG. 12 shows a flowchart of the processings of the IP addresstranslation facility (106) for sending an IP packet. In step 2301, thefacility (106) obtains both IP address and port number of the requestsource from the packet to be sent. In step 2302, the facility (106)stores the IP address and the port number of the request source in theIP address translation table (120).

FIG. 15 shows a structure of the IP address translation table (120).Column 1301 describes IP addresses of clients, column 1302 describesport numbers of clients, column 1303 describes translated IP addresses,and column 1304 describes converted port numbers. This table is a tableon correspondence used to identify converted IP packets and requestsources. In step 2303, the facility (106) translates the source IPaddress in the received packet to an IP address of the client managementdevice (101). In step 2304, the facility (106) converts the source portnumber in the packet to a free port number. Before this processing, thecurrently used port number must be stored in a memory. In step 2305, thefacility (106) stores both converted IP address and port number in theIP address translation table (120). Consequently, the facility (106)always translates any of different IP addresses of clients into one andthe same IP address.

FIG. 13 shows a flowchart of the processings of the IP addresstranslation facility (106) for receiving a packet. In step 2401, thefacility (106) obtains both IP address and port number of thedestination. In step 2402, the facility (106) searches the data matchingwith both IP address and port number obtained in step 2402 from the IPaddress translation table (120). In step 2403, the facility (106)translates the client IP address (1301) and the client port number ofthe searched in step 2402, as well as both IP address and port number ofthe received packet destination. In step 2404, the facility (106)deletes the entry from the IP address translation table (120). Thoseprocessings are based on the IP address translation method that managesa pair of an IP address and a source port number set in a packet issuedfrom a client, thereby the request source is identified uniquely evenafter the IP address translation. Consequently, the network file device(111) can manage areas easily, since the client management device (101)can translate IP addresses of a plurality of connected clients into oneIP address.

FIG. 14 shows how the above processings are performed more in detail. Aclient (1201) is connected to the client management device (1220) whilethe client management device (1220) is connected to the network filedevice (1212). The client (1201) issues a read request to the clientmanagement device (1220). In the read request (1202) are set the clientIP address 192.168.0.10, the client port number 2000, the clientmanagement device IP address 192.168.0.100, the port number 80 fordenoting the target service, the name of the file /user/A that theclient (1201) has requested to read. This makes the client (1201) thinkthat the client management device (1220) has the target disk. Receivingthis request, the client management device (1220) enables the virtualnetwork file facility (1204) to translate the disk address and adds/HUB01 to the read address just like the packet 1206 so that the addressis translated to /HUB01/user/A. If the address /HUB01/user/A is storedin the cache 1220, the facility (106) returns that to the client 1201.If not, the facility (106) passes the packet to the IP addresstranslation facility (1208). The facility (1208) then makes IP addresstranslation so as to translate the source address to 192.168.10.10 thatis the IP address of the client management device itself just like thepacket 1210. And, the facility (1208) assigns 10000 that is not used yetin the client management device (1220) as the source port number. Thefacility (106) then sets the IP address of the network file facility(1212) as the destination IP address. The destination port number is thesame as that issued from the client (1201), that is, 80. The networkfile device (1212), when receiving this packet (1210), reads the/HUB01/user/A file and stores the read data in the packet 1211, thenreturns the packet 1211 to the client management device (1220), which isthe direct request source. The client management device (1220), whenreceiving the packet from the network file device (1212), translatesboth IP address and port number to the client IP address and the clientissued port number through the IP address translation facility (1208)and the IP address translation table (1209) to generate a packet 1207.This packet (1207) is returned to the client (1201) through the virtualnetwork file facility (1204). As described above, because the clientmanagement device (1220) can make the client think that the target diskexists in the client management device (1220), it is hidden that aplurality of clients are actually connected to the network file device(1212).

FIG. 16 shows a flowchart of the processings of the negotiation facility(108) provided in the client management device (102). The negotiationfacility (108) establishes communication between the client managementdevice (102) and the network file device (111) correctly so that packetsflowing on the subject network are protected from illegal reading byillegal users and detecting such illegal users who pretend to be legalclients so as to read data, thereby disabling their connections. Thisflow is called when client management device (102) makes a connection tothe network file device (111). Then the flow is called periodically fromthe network file device (111). In step 1401, the facility (108) checkswhether or not the request is a device identification request. Thedevice identification request means a request issued by the network filedevice (111) to call and prompt the facility (108) periodically totransfer a device identifier to the device (111). If the check result isYES (device identification request), control goes to step 1407. If thecheck result is NO, control goes to step 1402. The facility (108)executes the processings in and after step 1402 at its first connectionto the device (111). In step 1402, the facility 8108) request the device(111) for establishing a connection therebetween. In step 1403, thefacility (108) encodes the device identifier. The device identifier isspecific to the client management device and used only between theclient management device and the network file device. Instep 1404, thefacility (108) transfers the device identifier encoded in step 1403 tothe network file device. In step 1405, the facility (108) checks if theconnection to the network file device (111) is established. This checkis done by notifying the network file device (111) of permission forconnection if the sent device identifier is authenticated by the networkfile device (111). If the check result is YES (established), controlgoes to step 1406 in which the facility (108) sends the device capacityusable by the client management device and the root directory of theclient management device to the device (111). The root directory is usedin step 1001, etc. shown in FIG. 10. There is also another flow that iscalled periodically from the network file device (111). The processingsin and after step 1407 are called periodically from the network filedevice (111). The object of this flow is to reject accesses with illegalIP addresses. The processings in and after step 1401 are executed by thefacility (108) when the client management device is started up. Theconnection between the client management device and the network filedevice is continued while the facility (108) sends the device identifierperiodically even after the start-up. In step 1407, the facility (108)encodes the device identifier. In step 1408, the facility (108) sendsthe device identifier encoded in step 1407 to the network file device(111).

FIG. 17 shows a flowchart of the processings of the negotiation facility(112) provided in the network file device (111). In step 1501, thenegotiation facility (112) accepts a connection request from the clientmanagement device (101). In step 1502, the facility (112) decodes thedata that includes the device identifier transferred from the clientmanagement device (101). In step 1503, the facility (112) checks if thedecoded device identifier is correct. If the check result is YES,control goes to step 1505. If the check result is NO, control goes tostep 1511, in which the facility determines the access to be illegal andshuts down the client management device (101). At this time, theshut-down range may be set freely. For example, the facility (112) mayshut down the device entirely and stops all the accesses therefrom orshuts down only the area allocated to the client management device. Instep 1505, the facility (112) sends both usable disk capacity and rootdirectory to the client management device. In step 1509, the facility(112) stops its processing for a certain time. In step 1506, thefacility (112) requests the client management device for a deviceidentifier. In step 1507, the facility (112) checks if the deviceidentifier is correct. If the check result is YES (correct) in step1508, control goes to step 1509. Otherwise, control goes to step 1510,in which the facility (112) shuts down the device. Consequently, thenetwork file device and the client management device can check thedevice identifier that is only known between them with each other evenwhen an illegal access occurs with a false IP address after the clientmanagement device is started up, thereby illegal accesses are detectedand data is prevented from illegal reading and altering.

Next, a description will be made for the client migration facility(109), which is another feature of the present invention.

FIG. 18 shows how network files are managed when a user moves from anetwork to another. In FIG. 18, reference numerals are defined asfollows; 1601 to 1603 denote migration client management tables(source), 1604 to 1606 denote migration client management tables(destination), 1610 denotes a disk, 1608 denotes a disk area allocatedto the migration client management device (source), 1609 denotes a diskarea allocated to the migration client management device (destination),1612 denotes data retained by a migration source client, and 1623denotes the destination of the data. If a client moves from a network toanother, at first the client in the client management table is moved tothe new network as denoted with 1607. After that, the client data isfetched from the source disk area 1612 as denoted with 1611 and copiedin the destination disk area 1613. Upon this data copying, the useridentifier must be changed. The user identifier is a user numberdetermined uniquely for each network. The user identifier is set foreach user file and the network file facility stores the identifier ascontrol information in a disk.

FIG. 19 shows a structure of a file management table. The column 1701describes file names, the column 1702 describes user identifiers, andthe column 1703 describes file attributes. Each user identifier 1702 isa unique user number determined by the manager of a network. The networkfile facility (113) uses such user identifiers to manage file accessprivileges. In the column 1703, for example, “r” enables reading and “w”enables writing. Usually, the manager updates data in the clientmanagement table while each client must make data migration byhimself/herself. Data migration is made, for example, as follows. Atfirst, the subject client copies the source data to the clienthim/herself. Then, the client moves to another network (networkmigration). At this time, the client gets a new user identifier from thenew network manager. The client then changes the user identifier ofhis/her file to a new one. At this moment, the user identifier of thecopied files is changed to the new one. After that, the client transfersthe copied file to the destination network file device (111). Thiscompletes the migration processing. This is why the present clientmigration processing casts a heavy work load upon the client.

FIG. 20 shows a flowchart of the processings of the client migrationfacility (109) (source) provided in the client management device (102).In step 1802, the client migration facility (109) accepts a request fromthe manager. The request from the manager is to obtain, for example, alist of clients to be migrated in the client management table. In step1802, the facility (109) makes an inquiry to the destination clientmanagement device according to the migration client information receivedin step 1801. In step 1803, the facility (109) waits for a response fromthe destination client management device about approval of themigration. At this time, the manager, when the migration is approved,notifies the client management device of the new user identifier of theclient. In step 1804, the facility (109) checks whether or not themigration is possible. If the check result is YES (possible), controlgoes to step 1805. If the check result is NO (not possible) control goesto step 1809. In step 1805, the facility (109) reads the target clientdata. In step 1806, the facility (109) sends the data read in step 1805to the destination client management device. In step 1807, the facility(109) waits for a response from the destination client management deviceabout whether or not the client data migration has been completed. Instep 1808, the facility (109) deletes the migration completed clientinformation from the client management table provided in the clientmanagement device (source). In step 1809, the facility (109) notifiesthe manager of the client management device of the migration result.

FIG. 21 shows a flowchart of the processings of the client migrationfacility (109) (destination) provided in the client management device(102). Instep 1901, the client migration facility (109) accepts amigration request from the client management device (source). Thisrequest includes information of the client to be migrated. In step 1902,the facility (109) inquires whether to migrate the client from themanager of the client management device (destination). In step 1903, thefacility (109) waits for the response from the manager. In step 1904,the facility (109) checks if the migration is possible. If the checkresult is YES (possible), control goes to step 1920. Otherwise, controlgoes to step 1909. In step 1920, the facility (109) notifies the clientmanagement device (source) of the possibility of the client migration.In step 1905, the facility (109) receives the client data from theclient management device (source). In step 1906, the facility (109)converts the user identifier of the received data to the new useridentifier notified in step 1802. In step 1907, facility (109) writesdata of the client whose user identifier is changed in a disk. In step1908, the facility (109) notifies the client management device (source)of the completion of the client data migration. In step 1909, thefacility (109) adds the migrated client information to the clientmanagement table provided in the client management device. In step 1910,the facility (109) notifies the manager of the completion of the clientmigration. As a result of execution of those processings, updating ofclient management tables and client data migration are enabled betweenthe client management devices (source and destination), thereby theclient can omit migration processings. In this embodiment, a descriptionhas been made for a procedure for changing a user identifier at the timeof data migration. If the client is not moved to a new network, however,there is no need to change the user identifier. Therefore, if clientmigration is determined to be made only in the present network, the useridentifier is not moved. It is also possible to change the useridentifier only when the client is moved to a different network.

In the first embodiment, a description has been made for a method forreducing the management load by managing clients in layers with use ofthe network file device and the client management device connected tothe network file device. And, the method can obtain the followingeffects. Because communication between the client management device andthe network file device is encoded, files are accessed in safe eventhrough a network to which many clients are connected, thereby theclient management load is reduced. In addition, because a cache isprovided in the client management device, data to be accessed frequentlyfrom clients is stored in the cache, thereby the access performance isimproved. And, because the network file facility enables only a specificclient management device to read/write data stored in the cache, data isnever read/written from/in the cache by anyone but the clientsregistered in the client management device. Thus, no access except thosethrough the client management device is made, so that no unmatchingerror occurs in the cache provided in the client management device.Furthermore, a large scale disk can be divided into a plurality of areasand a client management device can manage each of the divided areas.And, a maximum usable capacity can be set for each of the divided areas.This makes it easier for the network device manager to manage a largedisk area.

Second Embodiment

In this second embodiment, the client management device (102) describedin the first embodiment is built in the network file device (111).Because of such a configuration, it is possible to suppress themanagement load required for a large scale disk and reduce theimplementation cost.

FIG. 22 shows a block diagram of a network file device (2101) in thesecond embodiment of the present invention. The network file device(2101) is configured by a client management facility (2102), clientmanagement tables (2103, 2110), an IP address translation table (2120),a device capacity table (2104), a network file facility (2109), and acache (2111). A plurality of disks (2112) are connected to the networkfile device (2101). The operation of each block in this secondembodiment is the same as that of the block having the same function inthe first embodiment. The encoding processing in the first embodimentmay be omitted in this second embodiment. This is because the encodingprocessing is intended mainly to protect the data flowing in the subjectnetwork and the communication data is never checked by any third partywhen the client management facility (2102) is built in the network filedevice (2101) just like this second embodiment. Because the encodingprocessings can be omitted as described above, the processing in thissecond embodiment is speeded up more than in the first embodiment. Inaddition, while a cache is provided for each client management device inthe first embodiment, the cache provided in the network file facilitycan be used instead of such caches in this second embodiment, therebythe facility is simplified in structure. In spite of this, the clientmanagement method is the same between the first and second embodiments.And, the manager of the network file device (2101) is just required tosupply an area of a disk connected to the network file device (2101) toeach client management facility (2102), so that the manager of eachclient management device comes to manage clients actually, thereby manyclients are managed in layers. The client management facility may bedivided into a plurality of facilities. If a plurality of clientmanagement facilities similar to that one (2102) are provided for eachnetwork, it is possible to manage clients of many networks in layers.Each manager can thus access the network file device (2109) and theclient management facilities (2102) through those networks.

FIG. 23 shows a block diagram of a network in the second embodiment ofthe present invention. All the clients (2201) are connected to a networkfile device (2204) second embodiment is simpler in configuration thanthat in the first embodiment while it can obtain the same effects asthose in the first embodiment.

According to the present invention, it is possible to manage clients ofa large scale network storage system in layers, thereby the clients aremanaged more efficiently.

1. A network storage system for supplying a storage to a plurality ofclients through a network, said system comprising: a first deviceprovided with a disk device; and a second device for managing aconnection to said plurality of clients and relaying an access requestissued from a client to said disk device, wherein said first deviceallocates a portion of said disk device to said second device, whereinsaid second device divides said portion allocated by said first deviceinto a plurality of portions, and allocates each of the plurality ofportions to a respective one of each of said plurality of clients,wherein said second device is provided with means for translating asource network address of said client to a specific network address ofthe second device, the specific network address to be transferred tosaid first device, such that the means for translating translates eachof a plurality of network addresses of each of said plurality of clientsto the specific network address of the second device, and wherein saidsecond device adds a preset name of said portion allocated by said firstdevice to a file name included in said access request received from saidclient and transfers said file name along with said preset name to saidfirst device.
 2. The network storage system according to claim 1,wherein said system, when said second device is started up, encodes anidentifier specific to said second device, then transfers said encodedidentifier to said first device, while said first device decodes saiddevice identifier received from said second device and compares saiddevice identifier received from said second device with deviceidentifiers described in a table stored in said first device so as toenable devices described by the device identifiers to be connected totheir objects.
 3. The network storage system according to claim 2,wherein said first device requests said second device for transferringof its device identifier periodically, and inhibits said second deviceto access said allocated portion when receiving no response from saidsecond device or when said device identifier is not found in said tablestored in the first device and used to describe devices enabled toaccess said allocated portion of said disk device.
 4. The networkstorage system according to claim 1, wherein said first device, whensaid second device is started up, transfers the name of said allocatedportion to said second device.
 5. The network storage system accordingto claim 4, wherein said first device notifies said second device of ausable capacity when said second device is started up and said seconddevice makes a check whether or not said capacity is exceeded whenreceiving a write request from a client and rejects said write requestif said capacity is exceeded.
 6. The network storage system according toclaim 1, wherein said second device encodes a write or read request froma client, then transfers said encoded request to said first device. 7.The network storage system according to claim 1, wherein said seconddevice, when a client's file is to be transferred to another said seconddevice, determines whether or not said file is transferred betweendifferent networks and converts a user identifier described inmanagement information of said file if YES is a check result.
 8. Thenetwork storage system according to claim 7, wherein said second device,when having transferred said file, deletes the management informationrelated to said client who has transferred said file therefrom, and saidanother second device adds the management information related to saidclient thereto.
 9. The network storage system according to claim 1,wherein said second device is built in said first device.
 10. A networkstorage system connected to a network to which a plurality of clientsare connected, said system comprising: a network file device formanaging a plurality of disk devices; and a client management device forrelaying an access request issued from a client to a disk device andtranslating an address of the client to an address of the clientmanagement device, so as to access said disk device, wherein the clientmanagement device translates each of a plurality of addresses of each ofthe plurality of clients to the address of the client management device,wherein said network file device allocates a portion of each of theplurality of said disk devices to said client management device, whereinsaid client management device divides said portion allocated by saidnetwork file device into a plurality of portions, and allocates each ofthe plurality of portions to a respective one of each of said pluralityof clients, and wherein said client management device adds a preset nameof said portion allocated by said network file device to a file nameincluded in said access request received from said client and transferssaid file name along with said preset name to said network file device.11. A network storage system connected to a network to which a pluralityof clients are connected, said system comprising: a network file devicefor managing a plurality of disk devices; and a client management devicefor relaying an access request issued from a client to a disk device,wherein said network file device allocates a predetermined portion ofeach of said plurality of disk devices to said client management device,wherein said client management device divides said predetermined portionallocated by the network file device into a plurality of portions, andallocates each of the plurality of portions of said predeterminedportion to a respective one of each of said plurality of clients, andwherein said client management device adds a preset name of said portionallocated by said network file device to a file name included in saidaccess request received from said client and transfers said file namealong with said preset name to said network file device.
 12. The networkstorage system according to claim 11, wherein said network file devicehas a primary cache for storing copy information, which is at leastpartly disk device information, and wherein said client managementdevice has a secondary cache for storing part of said copy informationstored in said primary cache, which corresponds to said predeterminedportion allocated to said client management device.
 13. The networkstorage system according to claim 11, wherein said network file deviceand said network storage system are united into one unit.
 14. Thenetwork storage system according to claim 11, wherein said network filedevice and said network storage system are separated from each other andconnected to each other through a network.